Express Check Conversion 

B kg ROUND OF THE INVENTION 

5 TECHNICAL FIELD 

The invention relates generally to electronic checks processing. More particularly, 
the invention relates to a method and apparatus for automatically converting checks 
to ACH debits. 

10 

DESCRIPTION OF THE PRIOR ART 

Due to recent changes in the Automated Clearing House (ACH) by the National 
Automated Clearing House Association (NACHA), billers may now convert consumer 

15 checks that have been mailed to a lockbox into electronic ACH debits providing the 
biller has provided notice to the consumer. It is a difficult process to separate 
consumer checks from ineligible items, and, for consumer checks that are eligible for 
conversion, to correctly interpret and convert the on-us field of a Magnetic Ink 
Character Recognition (MICR) line into the correct format for an ACH debit. It has 

20 been found that, typically, items that are decisioned incorrectly, or parsed incorrectly, 
result in ACH administrative returns, wherein the returns simply state that the 
account number is invalid. 
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Currently there are three primary applications for electronic check conversion to ACH debits: 
re-presented check entries (RCK), point of sale (POS), and retail lockbox, or accounts 
receivable check truncation (ARC). 

5 Identifying items eligible for ACH conversion. 

Only consumer checks are eligible for conversion to ACH debits. Therefore, there 
must be a method in place for separating such eligible conversion items from money 
orders, travelers checks, cashier's checks, convenience checks (credit card balance 
10 transfer checks), commercial checks, government items, and the like, which are 
ineligible for conversion. 

Linking the MICR line with the Demand Deposit Account (DDA). 

15 Currently, there is no standard for how or where identifying numbers appear in the 
MICR lines of checks. The bank routing and transit number, although standardized, 
must be identified and captured within the MICR line. The check sequence number 
and account number must be identified, separated, and captured in the correct order. 
This is difficult not only because they may appear in various positions within the on- 

20 us fields of the MICR line but also because some financial institutions require a 
different account number for an ACH debit than they do for a check. 

In the case of credit unions using payable-through banks for check processing, the 
routing/transit number on the check MICR line is that of the payable through bank. 
25 The actual account number will likely contain a credit union identifier plus the 
account number. In order to convert a credit union payable-through draft to an ACH 
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transaction, the R/T number must be changed to that of the credit union, and the 
credit union identifier must be removed from the account number. 

Solving such" data "parsing^ challenges T^reatly~reduce exception items; improve- 
5 collection rates, improve processing quality, and satisfy consumer payment posting 
expectations.^ involve electronic payments, as follows. 

Carlson, Steven R. and Carlson, Paul R., Point-Of-Sale Device Particularly Adapted 
For Processing Checks, U.S. Patent Number 5,053,607 (October 1, 1991) disclose a 
10 check processing device that is particularly adapted for retailer/customer use at the 
point of sale through use of a MICR read head means, printer means and keypad 
means which feed information into a CPU which communicates, through an existing 
telecommunication system, with the customer's bank and the retailer's bank in order 
to transfer funds from the account of the customer to the account of the retailer. 

15 

Hills, Robert R. and Nichols, Henry R., Checkwriting Point Of Sale System, U.S. 
Patent Number 5,484,988 (January 16, 1996) disclose a point of sale system 
designed to read information from a consumer's check, credit card, or manual input 
with a subsequent debiting of a consumer's account and crediting a merchant's 

20 account for the goods or services provided. Point of sale terminals are designed to 
accept a form of credit card with a consumer's bank account information encoded 
thereon or in the alternative to read the MICR number from a consumer's check in 
order to verify that a consumer has an appropriate balance to conduct the 
transaction with a given merchant. Thereafter the transaction of that information is 

25 transmitted to a central computer system which verifies the consumer's credit 
worthiness and stores the transaction event information for subsequent bank 
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reconciliation via the ACH network. The invention eliminates the need for paper 
checks with all bank reconciliation being accomplished electronically. 

- Hillsr Robert R7 and Nichols; Henry R., Checkwriting Point Oi ' Sale System, U:S. 

5 Patent Number 6,1 64,528 (December 26, 2000), Checkwriting Point Of Sale System, 
U.S. Patent Number 6,283,366- (September 4, 2001 ) and Checkwriting Point Of Sale 
System, U.S. Patent Number 6,354.491 (March 12, 2002) disclose, in addition to the 
above summary, the disclosure includes fraud protection provisions such as velocity 
controls, social security checks, and scans. It claims to have the further flexibility to 
10 differentiate between "first time" consumer usage and those limits otherwise 
assigned to "known" consumer accounts. Additionally, there is not need for the 
system to retain the consumer's check after verification. 

% 

Weiner, S . EIectronic Payments in the U.S. Economy: An Overview . Federal 
15 Reserve Bank of Kansas City, Economic Review - Fourth Quarter 1999 discloses an 
overview of e-payments as they exist at that point in time in the U.S., including cash 
and check usage, credit and debit cards, wire transfers and ACH transactions, and 
e-money. 

20 Curley, B, First Union Division Offers Check Processing At POS. Bank Systems + 
Technology, vol.36, no.5 p. 40 (May 1999) discusses First Union offering electronic 
check processing at the point of sale (POS), where consumer checks are scanned at 
the POS using a check reader, such as an IVI Checkmate unit, which sends the 
MICR data through a dial-up network to BankServ, a San Francisco-based check 

25 processor. BankServ compares the check information against negative databases 
like Deluxe's SCAN. The cashiers are notified within seconds if a check comes up 
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bad; otherwise, BankServ sends the item for payment via ACM. Consumers receive 
a canceled check back at the POS, except for the first time they use a check for 
payment, when it is retained as a source document for the bank. 

5 It would be advantageous to provide a system and method that ensures that every 
item eligible for ACH conversion is converted and collected successfully. 

It would further be advantageous to eliminate administrative return processing resulting 
from the lack of MICR line standardization. 

10 

It would further be advantageous to provide a system and method that provides an 
ACH directory of the tens of thousands of routing and transit (R/T) numbers which 
identifies which R/T numbers are eligible for conversion, the R/T number and 
account conversion parameters, the formats of the on-us MICR line, and the ability to 
15 correct originated transactions. 

It would further be advantageous to store notifications of change that are sent by 
receiving financial institutions to update future originated transactions. 

20 It would further be advantageous to design a complete administrative return 
processing technique that allows for correcting and re-origiriating items (repair and 
re-originate converted ACH transactions) on behalf of customers without having the 
customers work, on the return and store the repaired transaction data to update 
future originated transactions. 

25 
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SUMMARY OF THE INVENTION 

A technique is provided for automatically converting checks to ACH debits. The 
— -process is a two-part process in which the M ICR line in l a checkls read at the point " 
5 the check is presented and a decision is made if the check can be converted to an 
ACH debit. The decision is made by applying various rules. If the system is unable 
to convert the check to an ACH debit, then the check is processed as a normal 
check. If a decision is made that the check can be processed as an ACH debit, then 
the MICR line is parsed for the financial institution which issues the check to create 
10 the ACH debit. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a schematic diagram showing the flow of the express check conversion 
1 5 process according to the invention. 

DETAILED DESCRIPTION OF THE INVENTION 

A technique is provided for automatically converting checks to ACH debits. The 
process is a two-part process in which the MICR line in a check is read at the point 

20 the check is presented and a decision is made if the check can be converted to an 
ACH debit. The decision is made by applying various rules. If the system is unable 
to convert the check to an ACH debit, then the check is processed as a normal 
check. If a decision is made that the check can be processed as an ACH debit, then 
the MICR line is parsed for the financial institution which issues the check to create 

25 the ACH debit. 
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It should be appreciated that the terms truncate and convert, and their various forms 
are used herein interchangeably. 

5 Check to ACH Conversion Overview 

A preferred embodiment of the invention can be described by the following 
discussion of improvements to an existing check to ACH conversion process. 

10 Customers (merchants, vendors, etc.) receive checks and other paper payment 
documents over the counter at retail point of sale or at a centralized lockbox location, 
deposit them, and wait up to 10 days for notification of returned items. 

Point of sale (POS) is a widely decentralized environment burdened by high 

r 

15 employee turnover rates and multiple equipment deployments. Checks accepted 
over the counter are usually subject to verification or guarantee by check services 
providers. These providers verify only the likelihood that sufficient funds are in the 
account to cover the check at the time it is accepted at POS. Other ineligible items 
including money orders, travelers checks, etc. must be deposited rather than 

20 truncated. 

Retail lockbox is currently a two-pass environment. Check and other paper 
payments, each accompanied by a payment coupon, come into the lockbox and are 
run through high-speed sorting equipment. On the first pass, the mail is opened and 
25 information is captured from the check and coupon. On the second pass, checks are 
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power encoded in order to create a cash letter for deposit. Lockbox customers 
typically rush to meet deposit deadlines at their local depository financial institutions. 

A Preferred Process 

5 

A preferred embodiment of the invention provides a method and apparatus ensuring 
that ACH truncation (or conversion) works for customers from end to end. On the 
front end, software upgrades and conversion tables are provided to assist customers 
in identifying ineligible items and in correctly parsing check MICR line information. 
10 On the back end, ongoing maintenance is provided as new returns appear and 
responsibility is taken for managing administrative returns: 

In Federal Reserve Routing and Transit Number database, there are over 55,000 
valid routing/transit numbers. Generally, about 28,000 of these are active. Of the 
15 28,000, approximately 26,000 accept ACH transactions. The claimed invention 
provides customers with the keys to parsing items successfully for ACH conversion. 
For items drawn on the approximately 2,000 financial institutions that do not accept 
ACH entries, the invention provides options to create and deposit drafts, thereby 
making a total electronic solution for customers. 

20 

Conversion Solutions 

A preferred embodiment of the invention provides conversion solutions designed for 
use with all three ACH conversion applications, as follows. Refer to Fig. 2. 

25 
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RCK. Electronic check representment (RCK) deals with converting consumer 
checks that have been returned for non-sufficient funds (NSF) or uncollected funds 
into ACH debits. Acting as the customer's ACH Originating Depository Financial 

-Institution (ODFI), and according to a preferred embodiment-of the invention r the- 

5 financial institution receives the returns and applies conversion logic to truncate them 
into ACH debits. The preferred embodiment of the invention provides check 
truncation decision processing methodology, which provides updating with 
administrative return information allowing customers to collect payments 
successfully. 

10 

POS. Ten billion to 20 billion checks are written at point of sale annually. In a 
preferred embodiment of the invention, in the PQS application, conversion logic is 
applied when a check is presented for payment. At the retail location, the cashier 
scans the check then calls for authorization. The check truncation decision 
15 processing logic resides on equipment at a centralized location rather than in the 
retail store. The cashier receives confirmation that the item can be converted to an 
ACH debit or, if it cannot, it must be deposited. 

ARC or Lockbox. Approximately the same number of checks are mailed to 
20 lockboxes, or placed in drop-boxes, as are written at point of sale. However, in 
these situations, high volumes of checks are concentrated in one location. From a 
technology deployment perspective, a great need for check conversion exists and, 
consequently, great benefits can be realized in a lockbox application. 

25 In the preferred embodiment, check truncation decision processing logic is applied to 
identify ineligible items at two points in lockbox processing: 1) the mail opening 
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process where non-standard checks as well as money orders, travelers checks, and 
the like are identified and separated; and 2) at a first pass through data capture 
equipment control point when ineligible items should be pocketed as deposit vs. 
truncated items- - — 1 

5 

Mail opening equipment uses basic Yes/No logic to detect inconsistencies in check 
sizes and in MICR lines lengths. Mail opening equipment does not look at R/T 
numbers or MICR line detail. To enable customers to identify items ineligible for 
ACH truncation, the invention provides software upgrades to make mail opening 

10 equipment smarter by outsorting ineligible items. Then, check truncation decision 
processing is applied, such processing methodology developed and maintained by 
electronic check experts or expert system, for use in the information capture process 
to identify any ineligible items that are not caught in the mail sort. The processing 
information, which is programmed into the software that runs the equipment, is 

15 driven by a particular consumer's billing account number as well as the R/T number 
and account number from the check. 

The check truncation decision processing methodology also provides the logic for 
parsing routines needed to correctly obtain the appropriate routing, and transit 
20 number, account number, and check serial number information needed to create a 
successful ACH transaction. 

Eliminating Administrative Returns 

25 Change is a fact of life. Consumers change payment behaviors from checks to 
money orders to online payment services whose payments arrive at lockboxes as 
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commercial checks. Credit unions change payable-through banks. Credit card 
companies begin using different R/T numbers, and their convenience checks begin 
flowing through. 

5 Just as antivirus software is updated continuously to identify and halt newly invented 
computer viruses, check truncation decision processing system is updated 
continuously to identify and convert new exception items. To provide customers with 
such ongoing maintenance, the preferred embodiment of the invention provides 
automated interfaces that notify and update customer platforms for new items as 
10 they appear. J 

Maintenance takes place on three levels. From highest to lowest, these are: 

• Routing/Transit Number (Institutional Level) 

15 

• Routing/Transit Number and Account Number 

• Consumer Billing ID (Consumer Level) * 

20 As customers encounter a new occurrence, the invention provides for taking the 
return item, examining the image, and determining what changes should preferably 
be made to re-originate the ACH transaction successfully. Thus, the burden of 
manual administrative return processing is off the hands of customers and any 
changes needed to be successful converting checks going forward are stored. 

25 

B n fits of Ch ck Truncation Decisi n Proc ssing M thodol gy 
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Following are some benefits of the Check Truncation Decision Processing 
Methodology according to the invention. 



5 Operating Cost Reduction 

When checks are converted to ACH debits at the lockbox, the number of passes 
through equipment decreases from two to one and operating expenses are cut in 
half. Checks need make only one pass through the sorting machines during which 
10 all information needed to create an ACH transaction is captured. There is no need to 
power encode the eligible checks because they will be converted to ACH entries. 

Accelerated Cash Flow 

15 Checks deposits are assigned same-day, one-day, or two-day funds availability, 
depending on their drawn-on banks. ACH debits receive next-day availability on all 
items. 

Fraud Risk Reduction 

20 

ACH returns are received faster than check returns allowing the customer to apply 
risk and fraud avoidance technology in a timely manner. With checks, customers 
may not receive NSF detail for up to 10 days after the initial deposit. Credit card 
companies, for example, benefit from being able to quickly modify the amount of 
25 credit that will be extended to delinquent payers and charging late payment fees. 
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Simplifi d R conciliati n 

The need for exception research is virtually eliminated. Financial institutions, such 

as-Wells Fargo,-supports the redepositing of-the transactions as well as the integrity - 

5 of the returns, taking all returns and matching them to originated' transactions to 
provide the best information possible about each return. With matching logic, 
customers receive the best possible return data. One preferred embodiment of the 
invention uses Wells Fargo's proprietary matching logic and matches 99.6% of the 
returns to the original items. Without Value-added matching logic, it has been found 
10 that only 86% of returns have completely accurate transaction information. 

Simplified Consumer Reconciliation 

The description of ACH payments on consumer account statements includes the 
15 name of the payee along with the check serial number, which does not appear when 
check payments are deposited. According to one embodiment of the invention, the 
correct check serial number is captured. Such capturing results in simplified account 
reconciliation for the consumer through less need for cross-referencing with check 
registers or duplicate checks copies, and,fewer consumer payment inquiries. 

20 

Return Savings 

Return costs for a check are in the $2 to $10 range versus $2 for an ACH item. 
25 R d posit Savings 
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It costs 33% less to redeposit an ACH return item than a check return, approximately 
$3 for a check vs. $2 for an ACH transaction. This becomes even more significant 
when considering that, for many customers, re-presentment of low-value items was 

not-cost-effective, so uncollected-payments were simply written off.- Now there is a - 

5 cost-effective solution to represent lowrvalue payments. 

Increased Collections 

Traditionally, checks that are returned for non-sufficient funds (NSF) or uncollected 
10 funds may be re-presented for collection once, unless RCK services are used. A 
consumer check thai has been converted to an ACH entry may be re-presented 
twice for a total of three presentments. Each presentment collects 30%-60% of 
outstanding items. 

15 Eliminated Check Storage 

Prior to the March 15, 2002 NACHA rule amendments, converted checks had been 
treated as Uniform Commercial Code (UCC) items. UCC retention requirements 
mandated that these items be stored for seven years. During the pilot period, the 

20 requirements were that the original check be retained for 90 days and an image of 
the check for seven years. As of March 15, 2002, truncated checks are supposedly 
treated as Regulation E items. On such date, the storage requirement is eliminated 
and replaced with a forced destruction requirement which requires the destruction of 
the original source document within 14 days in order to prevent double depositing of 

25 paper and ACH items, and reducing operating expense. 
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Applicability t Oth r ACH Participants 



The check truncation decision processing conversion solutions are applicable to all 

ACH conversion applications in which checks are-used-as the primary-source- 

5 document and, therefore, to virtually all ACH participants that accept checks for 
consumer payments. These solutions will improve transaction clearing and posting . 
for all ACH files. Companies billing recurring payments, particularly, will benefit from 1 
the provided information parsing keys as their files need the fewer updates and 
modifications over time. 

10 

Remittance Processing with Check Conversion 

This section describes Remittance Processing with Accounts Receivable Check 
Conversion, i.e. Express Check Conversion, according to one embodiment of the 
15 invention. 

What is Check Conversion? 

Paper checks received from consumers in payment of an account receivable, such 
20 as a credit card account, are converted to an electronic debit. The paper check is 
imaged and destroyed. The consumer sees detailed payment information on his or 
her bank statement. 

Check Conversion Process 

25 _ ■ 
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An embodiment of the invention is described with reference to Fig. 1 , wherein Fig. 1 
is a schematic diagram showing the flow of the express check conversion process. 
In one embodiment of the invention, a company mails a statement to a consumer 

(-102). The consumer -receives-the invoice-and conversion notification (104).— The 

5 consumer mails a coupon with the corresponding check (106), on route to the 
remittance processing center. The consumer mail is delivered to the company or to 
its associated lockbox, where payments are received and processed (108). Then, 
* the received and processed payments are sent to the company remittance 
processing center (110), which handles the following functionality: 

10 

o Converting eligible consumer checks 
o Creating electronic file for converted items 
15 o Depositing ineligible, paper checks at bank 

o Managing storage and retrieval of images 
The associated financial institution handles the following (112): 

20 

o ACH file processing and settlement 

* 

© Account maintenance 
25 o Returns handling . 
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• Customer service 



It should be appreciated that the company remittance site opening mail and 

_ processing payments for the company may be located at-the company itself or-at-a 

5 third party site. Regardless, the company can decide with which financial institution 
it wants to deposit ineligible items. Such financial institution may be different than 
the ODFI. For example, while lockbox processing is done in Florida, it may be that 
Wells Fargo Bank is the ODFI for the ACH items. However, because Wells Fargo 
does not have any branches or vaults in Florida, the company can decide to deposit 
10 the ineligible items with a local Florida bank. 

Remittance Processing Center 

The Remittance Processing Center provides the following functionality: 

15 

• Open envelope 

• Image payment 

20 • Determine payment amount 

• Associate payment with customer account 

• Determine if check is eligible for conversion 

25 ■ 
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Eligibl It ms 



Eligible items include: 



5 • Consumer checks only 

• Such checks having a pre-printed serial number 

• Such checks completed and signed by consumer 

10 

• Such checks of any dollar value 
Ineligible Items 

15 Ineligible items include: 

• Corporate checks 
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Third party checks 



Credit card checks 



Cashier's checks and money orders 



25 • Government checks 
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• Checks payable in a foreign currency 



• Checks containing an auxiliary on-us field 



Sorting Criteria 



Sorting criteria include: 



• The Customer database 



• Business customer 



• Opt out customer 



• Size of check 



• 6" denotes a consumer check 



• Larger size usually denotes a business check 



• Routing transit number on check 



• ACH acceptor or not 



• Format of MICR line 
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• Existence of auxiliary on-us field 
Sorting Function 

5 Checks are sorted as follows: 

• Eligible for conversion: 

• Add to "Perfect Parsing" file, described herein below. 

10 

• Ineligible for conversion: 

• Deposit in bank. 
15 Impact of Sorting Decision 

Following are described impacts of decisioning, as follows: 

• Accurate decisioning is essential to success. 

20 

• Inaccurate decisioning results in Administrative Returns: 

• The RDFI (receiving bank) is not able to process the ACH debit 
transaction. 

25 

• They return the transaction to the ODFI (originating bank). 

20 



• The ODFI returns it to the originating party for disposition (most likely, 
repair and re-origination) 



5 Sample MICR formats 

Two MICR myths include the following: 

o Bank account information is easily identifiable 
10 • 
• Check serial numbers are easily identifiable 

However, in reality, check conversion is complex, as can be inferred from the 
following sample MICR formats: 
15 \ > * " 

A21 1371078A 88 9999999C 5847 

A324377516A99999999999 3C 4195 j ) - 

20 A121101037A6622D99999999C09 
A231382306A 02 9999999C16 1712 
A121000248A322 9999 999999C 

25 

A322079353A 999999999C5283 10 

21 



A073901851 A 999D999C10 0623 

A121301028A 1234D9999C 2334 - 

5 

Parsing the MICR Line 

The following information provides guidelines and constraints for parsing the MICR 
line: - 

10 

• The "On-Us" field of MICR line on a check contains 20 characters. 

• ACH account format permits only 17 characters. 

15 • MICR may include a transaction ("TP) code which may or may not be a 

valid field for an ACH transaction. 

• The placement of the account number, serial number, and transaction' 
code in the MICR line is not standard across the banking industry. 

20 

• ACH transactions may require adding or removing leading zeros in the 
account number. } 

• Credit union share drafts often require R/T and account number 
25 reformatting to process as an ACH item. 

22 



MICR Parsing Options 

Some options for parsing are provided as follows: 



• Using a provided Decisioning Table to make decisions, parse within a 
customer's remittance processing environment and create a NACHA 
formatted file; or 

• Decision within the customer's remittance processing environment and 
create a "Perfect Parsing" data file and transmit to the financial institution 
facility for parsing via a Decisioning Table, such as an exemplary Decisioning 
Table described below; and 

• Use a third party software Decisioning Table, such as U.S. Dataworks, and 
create a NACHA formatted file. 

An Exemplary Decisioning Table 

An Exemplary Decisioning Table includes the following features: 

• A database of bank R/T numbers and account number and MICR parsing 
formats. 

• Daily, weekly, monthly analysis of all of a financial institution's ACH 
origination, return, NOC transaction data, including finding patterns. 

23 



• Means for Notifications of Change (NOCs) being automatically loaded and 
used to correct future originated transactions. 

-Using the Decisioning Table - 

Some ways for using the Decisioning Table are provided as follows: 

• Install the financial institution facility's database in the customer's platform 
and use it to determine eligible and ineligible items. Then send the resulting 
data file to the financial institution's facility, which then parses the data and 
creates and processes a NACHA formatted file containing the customer's 
transactions. 

• Install the financial institution facility's database in the customer's platform 
and use it to determine eligible and ineligible items. Then, the customer 
sends the full MICR line, amount, and the customer reference number to the 
financial institution facility, which then performs enhanced modifications and 
corrections, such as adding or deleting leading zeros, and credit union 
conversion modifications, and the like, and as discussed in detail herein. 

• Use third party software, such as U.S. Dataworks, to convert items and 
send the resulting NACHA formatted file to the financial institution's facility for 
further processing, as described in detail herein below. 

» 

Installing databas in custom r's platform 
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The following provides a way for successfully installing the decisioning table 
(database) in the customer's platform: 

Incorporate the database into the customer's software program to assist in - 

5 determining which checks are eligible for conversion. 

• Updating the database weekly or monthly from a transmitted file sent from 
the financial institution's facility to the customer. 



"Perfect Parsing" File 

Following is a way of creating and using the Perfect Parsing file: 
15 ' 

• Capture the R/T number field, the on-us field, and determine the amount of 
checks eligible for conversion. 

• Send the "Perfect Parsing" file to the financial institution without editing the 
20 transaction data. 

• Let the financial institution parse the data, and: 

• Create and process a NACHA formatted file for eligible conversion 
25 items. 
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• Create paper drafts for ineligible items. 

It should be appreciate that the resulting NACHA formatted file will have the lowest 
possible administrative return rate^because, among other things: - 

1) the decisioning is correct; and 

2) the back-end ACH formatting can be performed after the NACHA file is received. 
Third Party Software 

Following describes a way to incorporate third party software into the check 
conversion decisioning process: 

• It should be appreciated that the Decisioning Table can still add value to 
files already parsed by other's software, 

• The provided R/T data is more current than the data available from 
"official" bank tables, so R/Ts that are out-of-date can be corrected. 

• The effectiveness of the provided Decisioning Table in correctly parsing 
account numbers is somewhat reduced because parsing eliminates some 
data from the MICR line that may otherwise be essential. 
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• Leading zeros to account numbers are still added/removed, thereby 
reducing administrative returns. 

- Credit union conversion modifications are provided. 

5 * 
Process Flow - Ineligibles 

Following are guidelines provided for the ineligibles process flow: 
10 • Power encode the ineligibles with the given dollar amount. 

• Due to the lower volume of checks deposited, special sorting of checks 
may no longer be needed. 

15 • Depending on the mix of business/consumer checks, decide possibly to 

deposit the checks without encoding the dollar amount. 

• Deposit at bank. 

20 Process Flow - Eligible Checks 

Following are guidelines provided for the eligibles process flow: 

• Mark checks void on transport (optional). 

25 

• Confirm that images are readable. 
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• Transmit file to the financial institution for processing. of ACH debits. 

_.. # ._ _ Destroy cheeks-that -have-been converted to-AGH debits within a 

5 predetermined number of days, e.g. 14 days, of the settlement date. 

An Exemplary Express Check Conversion Embodiment 

10 Maintained Tables 

In a bank's directory, such as Wells Fargo Bank Directory, containing over 60,000 
routing and transit numbers, the following is provided, The preferred table identifies: 
active versus retired R/T numbers, ACH participating R/T numbers, credit union 
15 conversion identification and translation information, check conversion eligibility 
flags, invalid account lengths, minimum and maximum account lengths, parsing 
format codes, and trim lead zero indicator. 

MICR Translation Table. The table contains a list of masks for ail of the possible 
20 MICR on-us field variations with the corresponding location of the account number 
and check serial number. Some masks are duplicated on the table with parsing 
format identifiers that match options available on the Bank Directory. 

Transaction Management Database. This table stores all originated check 
25 conversion transactions and corresponding transaction modifications needed for 
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future transactions. The transaction modifications are a result of received 
notifications of change and administration (admin) return processing. 

5 

Process Flow 

The financial institution facilitator provides initial and on-going files of ineligible R/T 
10 numbers to customers. 

Customers utilize an ineligible R/T numbers list to sort checks into eligible and 
ineligible items. Ineligible items are encoded and deposited as checks. Due to the 
NACHA Rules, the customer also must identify checks containing an auxiliary on-us 
15 field as ineligible items.. 

For eligible items, customers format an Perfect Parsing file containing a record for 
each check. The file format consists of 9 byte R/T number, 20 byte MICR on-us field 
(including all spaces, dashes, and symbols), 10 byte dollar amount,. and 22 byte 
20 client reference number. 

The financial institution processes the Perfect Parsing file and creates a NACHA file 
of transactions for origination. Each record in the Perfect Parsing file is matched to a 
mask on the MICR Translation Table to identify the correct location of the account 
25 number and check serial number used for the NACHA formatted file. The parsing 
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format for each R/T number located on the Bank Directory is also used to identify 
which mask to be used in the case of duplicate masks. 

: An -internal processing systemis-benchmarked at six million-items-in-and out of the 

5 ACH warehouse per hour, which is needed to support the high volume of check 
conversion activity. 

In addition to the creation of the NACHA file, items are automatically drafted as 
needed to collect items from R/T numbers that may have changed their ACH 
10 participation status after the customer had loaded their ineligible R/T numbers list. 

Generally speaking, there are two reasons drafts are created for institutions: 

1) The institutions have changed their participation status; and 

15 

2) The credit union conversion logic currently reflects that the credit union doesn't 
accept ACH. For example, if a payable through bank processes for 100 credit 
unions, all the.sharedrafts will have the same payable through R/T number, but a few 
of the credit unions may hot accept ACH. 

20 

As the NACHA files are entered into the financial institution's ACH warehouse, the 
files are identified as either on-us items, or transit items. Ori-us items are distributed 
to the financial institution's posting application, and transit items are distributed to the 
ACH Operators for delivery to the appropriate receiving financial institutions. 

25 
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Several times during the day, the financial institution receives returns from originated 
electronic check transactions. Once per day, it processes all the returns, sorting and 
distributing the fatal return items to customers and preparing settlement. All 

Notifications- of- Change (NOC) are- loaded into-a-Transaction-Management 

5 Database. Based on a pre-determined list of return reason codes, admin returns are 
also sorted and distributed to a Unix-based server for ACH operation staff to repair 
and re-initiate corrected entries (admin return processing). 

The admin return processing system allows viewing all details of the original 
10 transaction and the return, for example, by a staff or expert system. Each return is 
matched to the original item to allow the ability to validate the return detail 
information. All of the transaction information, as well as an image of the check is 
used to repair the item. The following ability is provided: 

Correct and re-originate an ACH item 

Correct and draft an item 

Dishonor the ACH return 

Take a copy of the image to produce an image replacement document 

All operator repairs are loaded into a Transaction Management Database to be used 
for future originated transactions, thereby eliminating future admin returns. 

25 

MIS R porting 



15 



20 
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To manage the on-going maintenance of the Bank Directory, ACH operations 
provides daily, weekly, and monthly reports produced which highlight origination 
detail and rates, return detail and rates, and admin return detail and rates, both by 

, originating customer and by receiving financial institution. — — — 

5 

The Bank Directory is updated with a Federal Reserve ACH participant listing and by 
a Thomson directory for bank name, address, and contact information. 

Exemplary NOC Logic 

10 

The preferred embodiment of the invention uses NOCs received for Check 
Conversion transactions to modify the (R/T)/Account/Transaction code for future 
Check Conversion Transactions, discussed as follows. 

* . 

15 It should be appreciated that this NOC logic is only applied for valid NOCs received 
for check conversion transactions, such as any of: routing and transit number 
changes, account number changes, transaction code changes, and the like. 

When a check conversion transaction's received from a check conversion customer, 
20 perform the following steps: 

Apply the existing check conversion logic for modifying the 
(R/T)/account/check/transaction code number; 

25 Check if a matching NOC was received in the NATBCCHG database. If there is 
a match, use the NOC information to set the R/T, Account, and Transaction code. 
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It should be appreciated that If the (R/T)/Account/Transaction code is modified 
because of a previously received NOC, write a record to the NOC FILE with 
"WFBDPN-'.ih-the descriptive date field to indicate the code was modified because of 
a previous NOC. These are not written to the final NOC file used to send out NOCs, 
but are used to add a record to NATBCCHG. Therefore, if a RETURN or NOC is 
received later for a transaction because of a previous NOC, such RETURN or NOC 
appears on the new relevant report. 

If returns are received for a transaction in which the RT/Account/Transaction code is 
modified because of a previous NOC, that NOC record is deleted from NATBCCHG 
so that future transactions for that RT/Account are not altered. 

If a check conversion transaction was not received for thirteen months for a matching 
RT/Account, then such transaction from NATBCCHG is removed. 

It should be appreciated that reports include all customer provided transaction detail 
in addition to the resulting NACHA formatted transaction detail. 

It should be appreciated that the "CODE" is "N/A" when the account is modified from 
our check conversion logic but did not create an NOC. The "CODE" is "PN" when 
the (R/T)/account/transaction code is modified because of a previous NOC, but a 
new NOC is not sent. 



33 



It should be appreciated that the invention allows inquiries, updates, deletes, and 
adds to the NOC records in the NATBCCHG database to alter how the 
RT/Account/Transaction code is changed for check conversion transactions. 

Below, Table K is an example NOC report according to the invention. 



Table K. 



REPORT H875-1 
.LOCATION: XXXX 
DATES: MM/DD/YY - MM/DD/YY 



TOP OF REPORT 

AUTOMATED CLEARING HOUSE 
CHECK CONVERSION WFBD RETURNS 



SYS DATE: MM/DD/YY 
SYS TIME: HH : MM 
PAGE : XXXX 



CUSTOMER R/T/ CUSTOMER ACCT#/ CUSTOMER CK#/ CUSTOMER TRAN RET/NOC 

ORIGINATED R/T ORIGINATED ACCT# ORIGINATED CK# ORIGINTED TRAN DATE CODE NOC INFO 



XXXXXXXX XXXXXXXXXXXXXXXXX XXXXXX 

XXXXXXXX XXXXXXXXXXXXXXXXX XXXXXX 

XXXXXXXX XXXXXXXXXXXXXXXXX XXXXXX 

XXXXXXXX XXXXXXXXXXXXXXXXX XXXXXX 

XXXXXXXX XXXXXXXXXXXXXXXXX XXXXXX 

XXXXXXXX XXXXXXXXXXXXXXXXX XXXXXX 



XX . XXX 

XX MM/DD/YY XXXXXXXXX 

XX XXX 

XX MM/DD/YY XXXXXXXXX 

XX ' XXX 

XX MM/DD/YY XXXXXXXXX 



TOTAL WFBD RETURNED ITEMS XXXXX 



END OF REPORT 



An Exemplary Express Check Conversion Design - Technical Requirements 
and Detailed Design 



Objective 
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The objective of this endeavor is to enhance the support of Check Conversion 
transactions, effective with the NACHA 2002 release. 

Background — — 

5 

ARC transactions used for Check Conversion are part of the NACHA 2002 release 
on March 15, 2002. Not all checks are eligible for check conversion. In order to 
make better decisions up front on the eligibility, this embodiment of the invention 
allows maintaining information at the bank R/T level to determine whether the check 
10 is allowed in the check conversion process. 

This database of check conversion decision information is made available to check' 
conversion originators to allow better up front decisions in determining whether the 
truncate. 

15 

This embodiment of the invention also allows reporting on the volumes. 

An Administrative Returns process allows correcting any check conversions that get 
returned by comparing the actual image to the check conversion transaction created. 

20 

It should be appreciated that in the industry, it is imperative that high speed 
processing be retained with check conversion. The preferred embodiment of the 
invention retains such high speed processing with check conversion because the 
invention provides a "thin" file of ineligible R/T numbers. 

25 

Check Conversi n D cisi n Database R quir m nts 
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TDB1 - Eligibility Indicator by R/T number 



TDB1 is an eligibility indicator-required for-eaeh-R/T numbeHo-indicate whether~the~- 

5 routing and transit number will accept truncated ACH items or MICR drafts. 

TDB1 contains logic handling the case when even though an R/T number can accept 
ACH, it may not accept converted checks, and when this is the case, the R/T number 
Ms part of the ineligible R/T number file. 

10 

If the R/T number is not eligible, a reason code is maintained to indicate the reason 
that this R/T number does not accept the truncated ACH/MICR items. 

TDB2 - Ineligible Account Number Length 

15 

For R/T numbers that are eligible for truncated ACH and MICR items, an ineligible 
account number length is defined. Such allows setting a minimum account number 
length that is not valid for truncated ACH or MICR items. For example, if this value is 
set to 13, account numbers with a length 13 or more are not eligible for check 
20 conversion transactions. Lengths less than 12 are allowed. 

TDB3 - Minimum/Maximum Account Number Length 

A minimum and maximum account number length can be specified for R/T numbers 
25 that accept check truncation transaction. There is a minimum and maximum account 
number length. 
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If the length of the account number received on a check conversion transaction is 
less than the minimum account length defined, then lead zeros are added to get to 

.this minimum length. — 

5 

If the length of the account number received on a check conversion transaction is 
greater than the maximum account length defined, then the account number is 
truncated to get to this maximum length. 

10 Such minimum and maximum account number length fields are also used in 
conjunction with ineligible items' account length to determine whether or not to 
modify such account length or use the action code for the ineligible length. 

TDB5 - Truncate Leading Zeros Indicator 

15 

An indicator at the R/T number level is provided to determine whether leading zeros 
should be truncated for this R/T number. If set to "Y", then leading zeros are 
truncated. However, if the truncated account length is less than the minimum 
account number length defined for this R/T number, then lead zeros are used to get 
20 to the minimum account number length. 

TDB6 - Parsing Formats 

A parsing format code is used to indicate how the MICR line of a check should be 
25 parsed for this; R/T number. This code is needed by the originator facility that is 
doing the actual conversion. 
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Some sample formats are as follows: 

00 - Unknown format -— 

01 - *R/T*account number/ check serial number 

02 - *R/T*check serial number account number 

03 - *R/T*check serial number account number/account number (use numbers 
after on-us auxiliary field to create account number) 

04 - *R/T*check serial number account number/account number (do not use 
numbers after on-us auxiliary field to create account number) 

05 - *R/T*account number/account number check serial number (use numbers 
after on-us auxiliary field to create account number) 

06 - *R/T*account number/account number check serial number (do not use 
numbers after on-us auxiliary field to create account number) 

07 - *R/T*00000account number/ check serial number (various number of 
leading zeros before account number, use zeros to create account number) 
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08 - *R/T*00000account number/ check serial number (various number of 
leading zeros before account number, do not use zeros to create account 
number) 

5 09 - *R/T*account number/check serial number (SPECIAL EDIT: If the check 
serial number is six digits, then the last two digits are stripped from the check 
number without a NOC) 

, f 10 - *R/T*account number/check serial number (SPECIAL EDIT: If the check 
10 serial number is 6 digits, then the first two digits are stripped from the check 
number without a NOC) 

11 - *R/T*account number/check serial number (SPECIAL EDIT: If the check 
serial number is six digits, then the first two digits are stripped from the check 
15 number and placed at the end) 

Check Conversion Decision Processing Requirements 

This section only addresses the technical design for requirements of a first phase. 

20 

TDB7 - Invalid Account Length Action Code 

An action code for Invalid Account Length for instructing how to process transactions 
whose account length is greater than or equal to the Invalid Account Length. Such 
25 Action Code can be "R" to reject the transaction or "D" to draft it via MICR. 
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D sign Ov rview 

See JCL section below for new JCL streams. 

5 See Scheduling section below for Scheduling changes. 

) 

Project Test Libraries 

The following TSO libraries are used to create and store all new JCL, Procs, and 
10 Control Cards needed for both unit testing and system testing. 

JCL Library 

TSTNA.#TEAMA.JCLLIB 

15 

Proc Library 

TSTNA.$PD3355A.PROCLIB 
20 Control Card Library 

TSTNA.$PD3355A.CNTLCARD 

f 

Dataset Naming Conventions 

25 
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Whenever possible, all datasets used for testing should follow the following dataset 
naming standards: 



. •_ All datasets beginning with TSTNA are test datasets. — ~ 

5 

• All datasets beginning with PRDNA are production datasets. 

• An optional third qualifier may be added to identify the program or job that the 
dataset is created or used in. 

10 

• Productions dataset names follow naming standards defined in the ACH phase 2 
standards document. 

JCL 

15 

New JCL 
ZNACHKTB 

20 Such is a weekly job executed on Saturdays for executing PROC NACHKT to build 
the new generation of the Check Conversion Parameter File. 

ZNAD300A 
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Such is a job to produce the Check Conversion Problem Report by R/T on a daily, 
weekly, and monthly basis. It executes proc NAD300. There are preferably three 
SCHID's: one for daily, one for weekly, and one for monthly. 



5 ZNAD310A 

Such job produces the Check Conversion Problem Report by File ID/Company ID on 
a daily, weekly, and monthly basis. It executes proc NAD310. There preferably are 
three SCHID's: one for daily, one for weekly, and one for monthly. 

ZNAD320A 

Such job produces the Check Conversion Detail R/T Report on a daily basis. It 
executes proc NAD320. 
15 ' 
ZNAD330A 

Such job produces the Check Conversion Detail File ID/Company ID Report on a 
daily basis. It executes proc NAD330. 

20 

ZNAS400C • 

Such is a monthly job to produce the Monthly Availability Report. It executes proc 
NAS400. 

25 

JCL Changes 
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ZNAOA03A 



Such job selects records from a preexisting NATBCPNY and builds a dataset to 

download information to UNIX, -The LREGL=797 is increased on both job steps to 

5 accommodate the additional field added to the select. The LRECL=968 is increased 
by two to allow the delimiter (|). 

ZNAOA04A 

10 Such job selects records from NATBFILS and builds a dataset to download 
information to UNIX. The LRECL=450 is increased on both job steps to 
accommodate the additional field added to the select. The LRECL=579 is increased 
by two for the new field and delimiter. 

15 ZNAOA1 2 A 

Such job selects records from NA4VCMPR and builds a dataset to download 
information to UNIX. The LRECLs preferably are changed to add the Credit Union 
Conversion and Check Conversion parameters. 

20 

Scheduler 

New Scheduler Jobs 
25 ZNACHKTB 
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This is a weekly job executed on Saturdays that executes PROC NACHKT to build 
the new generation of the Check Conversion Parameter File. 

-ZNAD300A - : 

5 

Such is a daily job to produce the Check Conversion Problem R/T Report 
ZNAS400C 

10 Such is a monthly job to produce the Monthly Availability Report for check 
conversion customers. 

Procs 

15 New Procs 
NACHKT 

Such PROC is used to execute the new program NAD0110 to build the new 
20 generation of the Check Conversion Parameter file. 

NAD300 

Such PROC executes NAD0130 to produce the Check Conversion Problem R/T 
25 Report by RT. 
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NAD310 v 

Such PROC executes NAD0310 to produce the Check Conversion Problem R/T 

Report by File ID/Company ID. 

5 

NAD320 

Such PROC executes NAD0315 and NAD0320 to produce the Check Conversion 
Detail Report by R/T. , 

10 

. NAD330 

Such PROC executes NAD0315 and NAD0330 to produce the Check Conversion 
Detail Report by File ID/Company ID. 

15 

NAS400 

Such PROC executes NAS0400 to produce the Monthly Availability Report. 
20 Control Cards 

New Control Cards 
NAD30.0S1 

25 
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Such control card sorts records created by NAD315 for NAD300 by R/T to build the 
Check Conversion Problem Report by R/T.. 

NAD310S1 

5 

Such control card sorts records created by NAD315 for NAD310 by R/T to build the 
Check Conversion Problem Report by File ID/Company ID. 

NAD320S1 

10 

Such control card sorts the records created by NAD315 for NAD320 by R/T to build 
the Check Conversion Detail Report by R/T. 

NAD330S1 

15 

Such control card sorts the records created by NAD315 for NAD330 by FILE 
ID/Company ID to build the Check Conversion Detail Report by File ID/Company ID. 

Control Card Changes 

20 

NANCCPNY 

Such control card selects the NATBCPNY fields for sending to the UNIX. Add the 
new columns to the SELECT statement. Add FADMRT as the last select field. 

25 

NANDCPNY 
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Such control card has the output statements for building, the NATBCPNY file to send 
to the UNIX. A new statement is added at the bottom for outputting the new 

FADMRT field. 

5 

NANDAH03 

Such control card has the NDM statements for sending the NATBCPNY information 
to the UNIX. The LRECL increases from 968 to 969. 

10 

NANCFILS 

Such control card selects the NATBFILS fields for sending to the UNIX. Add the new 
columns to the SELECT statement. Add FCTIND as the last select field. 
15 - • 

NANDFILS 

Such control card has the output statements for building the NATBFILS file to send 
to the UNIX. A new statement needs to be added at the bottom for outputting the 
20 new FCTIND field. 

NANDAH04 

Such control card has the NDM statements for sending the NATBFILS information to 
25 the UNIX. The LRECL increases from 579 to 580. 
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NANCCMPR 



Such control card selects the NA4VCPNY fields for sending to the UNIX. Add the 
_ — new columns for Gheck-Gonversionr Send the credit-union conversion fieldsr 

5 . ' 

Add CCTIND, QCTIAL, QCTMNL, QCTMXL, CCTPFM, FCTTLZ, CCTILA, 
CUIDPOS, CREDITUNID, IRTCCU, CUACCOUNTFLG, CRUNIONPRCS, 
CURTTFLG. 

10 NANDCMPR 

Such control card has the output statements for building the NA4VCMPR file to send 
to the UNIX. New statements are added at the bottom for outputting the additional 
fields CCTIND, QCTIAL, QCTMNL, QCTMXL, CCTPFM, FCTTLZ, CCTILA, 
15 CUIDPOS, CREDUTUNID, IRTCCU, CUACCOUNTFLG, CRUNIONPRCS, 
CURTTFLG. 

NANDAH12 

20 Such control card has the NDM statements for sending the NA4VCMPR information 
to the UNIX. The LRECL increases for the new fields. 

NAG150CU 
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Such control card is used for selecting Credit Union NOCs from NAR562's 
NOCFILE. It is preferably modified for the C99 NOCs because neither FNOCA nor 
FNOCB are likely to be turned on. Select records with WFBD as the descriptor. 



5 Files 

New Files 

PRDNA.Z1 70001 A.SCHKTPRM.R0008(0) 

10 

This is a GDG to contain the most recent copy of. the Check Conversion Parameters 
defined by segment WY25. The last three generations preferably are kept. 

Such file is built on a weekly basis with a new job. 

15 

PacBase Elements 

New Elements 

20 FCTIND * 

Check Conversion indicator, PIC X(1). Values of "Y" for Yes. All other values are 
NO. 

25 CCTIND 
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Check Conversion indicator, PIC X(1). Values of "Y" for Yes. All other values are 
NO. 

QGTMNL- - 

5 

Check Conversion minimum account length. PIC 9(2). Also create child QCTMNC 
with internal format 9(2) for putting it in an output file for the customer. 

QCTMXL 

10 

Check Conversion maximum account length. PIC 9(2). Also create child QCTMXC 
with internal format 9(2) for putting it In an output file for the customer. 

FCTTLZ 

15 

Check Conversion Truncate Lead Zeros indicator ,PIC X(1). Values of "Y" for Yes 
and "N" for No. 

CCTPFM 

20 

Check Conversion Parsing Format, PIC 9(2). Also create child CCTPFC with 
internal format 9(2) for putting it in an output file for the customer. 

QCTIAL 

25 
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Check Conversion Invalid Account Length, PIC 9(2). Also create child QCTIAC with 
internal format 9(2) for putting it in an output file for the customer. 

CCTNOC . ; — ' ~ 

5 

This is a code to indicate the. reason why the account number was changed as a 
result of the Check Conversion parameters. PicisX(1). Values: 

SPACE = Not affected by check Conversion parameters 

10 

A = Changed due to M IN/MAX account length parameters 
B = Changed due to Trim Lead Zero option 
15 C = Forced to MICR because member bank does not process ACH 
FADMRT 

Admin Returns Indicator, PIC X(1). Values of "Y" for Yes and "N" for No, 

20 

CCTILA * v 

Check Conversion Invalid Length Action Code, PIC X(1). Values of "R" to reject the 
item or "D" to draft using MICR. 

25 

CDLYMO 
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Daily or Monthly indicator for report programs. 



Q6TMNX- 

5 

Check Conversion minimum account length display. PIC 9(2). Also create child 
QCTMNC with internal format 9(2) for putting it in an output file for the customer. 

QCTMXX 

10 

Check Conversion maximum account length display. PIC 9(2). 

CCTPFX - 
15 Check Conversion Parsing Format Display, PIC 9(2). 
QCTIAX 

Check Conversion Invalid Account Length Display, PIC 9(2). 

20 

PacBase Segments 

New Segments 
25 WY25 - Check Conversion Parameter File 
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This is a new segment that defines the record layout of the Check Conversion 
Parameter File that is created on a weekly basis and sent to originators of Check 
Conversion Parameters. 

5 The following elements preferably make up this file: 

IRTC - Bank RT with Check Digit - PIC 9(9) 

NBNK50 - Bank Name - PIC X(50). 

10 

CCTIND - Check Conversion Indicator (Y/N) - PIC X(1) 
QCTIAL - Invalid Account Length - PIC 9(2) 
15 QCTMNL - Minimum Account Length - PIC 9(2) 
QCTMXL - Maximum Account Length - PIC 9(2) 
FCTTLZ - Trim Lead Zeros Indicator - PIC X(1) 

20 

CCTPFM - Parsing Format Code - PIC 9(2) 
CBKST - Bank Status PIC X(1 ) 
25 FMSPL-ACH Member Status PIC X(1) 
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WY27 - Report Program Parm Card 

This is a new segment that defines the linkage section PARM card to be passed to 

the NAD300 and NAD310 report programs. r- 

5 

The following elements preferably make up this file: 
IREG- Region 
10 ILCTNX- Location 

CDLYMO - Daily, Weekly, Monthly code 
DFMTI Overriding from date 

15 

DFMTI2 - Overriding to date 

WY29- Check Conversion Detail Report Work File 

20 This is a new segment that defines the work file created by NAD315 to be used by 
report programs NAD320 and NAD330. 

The following elements should make up this file: 

25 CADNOC - Admin/NOC code 
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IRTC - R/T number with check digit 



IACCT - Account number 
5 FILE -FILE ID 

ICPNY- COMPANY ID 

IIND - Individual ID (Has serial number 

.10 

CTRANA - ACH transaction code 
CRESR1 - Return/NOC 3 digit code 
15 Segment Changes 
GA20 

this segment is for NATBCMPR and needs to have CCTIND, CCTRSN, QCTIAL, 
20 QCTMNL, QCTMXL, FCTTLZ, CCTPFM, and CCTILA. 

GA22 

This segment is for NATBCMPR and needs to have CCTIND, CCTRSN, QCTIAL, 
25 QCTMNL, QCTMXL, FCTTLZ, CCTPFM, and CCTILA. The -DBE entries should 
point to GA20. This is for NA1VCMPR. 
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GA23 



ThiS-segment isTor NATBCMPR-and-needs-tohave GGTINDr QCTIAL, QCTMNLr 

5 QCTMXL, FCTTLZ, CCTPFM, and CCTILA. The -DBE entries should point to 
GA20. This is for NA2VCMPR. 

GA24 

10 This segment is for NATBCMPR and needs to have CCTIND, QCTIAL, QCTMNL, 
QCTMXL, FCTTLZ, CCTPFM, and CCTILA. The -DBE entries should point to 
GA20. This is or NA3VCMPR. 

GA25 

15 

This segment is for NATBCMPR and needs to have CCTIND, QCTIAL, QCTMNL, 
QCTMXL, FCTTLZ, CCTPFM, and CCTILA. The -DBE entries should point to 
GA20. This is NA4VCMPR. 

20 AG00 

This segment is used for common control information. Currently it contains the NOC 
indicators for R/T change (FNOCA) and Account number change (FNOCB). At the 
bottom of this segment, add CCTNOC to contain the NOC Check Conversion 
25 indicator. 
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GA5C 



This segment is for NATBFILS and needs to have FCTIND added to the bottom. 



5 GA5D 

This segment is for NATVFILS and needs to have FCTIND added to the bottom and 
the -DBE to point to GA5C. 

10 GA5A 

This segment is for NATBCPNY and needs to have FADMRT added to the bottom. 
GA5B 

15 

This segment is for NATBCPNY and needs to have FADMRT added to the bottom 
and the -DBE to point to GA5A. 

DD1T 

20 

This segment is the audit log descriptions for GA5B and needs "ADM RETURN" 
added for a description. 

DF1T 
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This segment is the audit log values for GA5B and needs FADMRT added to the 
bottom. 

... WS38 

5 . 

This segment is for the NAC210 DB2 work area for the ACF setup report and needs 
FCTIND and FADMRT added to the bottom. 

DD5D 

10 , . 

This segment is the audit log descriptions for GA5D and needs "CHK TRUNC" 
added for a description. 

DF5D 

15 

This segment is the audit log values for GA5D and needs FCTIND added to the 
bottom. 

GA1J 

20 

This segment needs a key added for IRTVI to be used as a key for NAD300 Check 
Conversion report when reading NATVRHST. 

DD2A 

25 
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This segment is the audit log descriptions for GA23 and needs the Check Truncation 
fields added. 

5 

This segment is the audit log values for GA23 and needs the Check Truncation fields 
added. 

DB2 

10 

New DB2 Tables 
None. 

15 DB2 Table Changes 

NATBCMPR - Bank File Directory 

The new Check Conversion Database Decision fields that are based on the BANK 
20 R/T are kept in the Bank File Directory table. The following new rows are to be 
added to this table: 

CCTIND - Check Conversion Indicator - X(1 ) 

25 QCTIAL - Check Conversion Invalid Account Length - PIC S9(3) COMP-3 
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QCTMNL - Check Conversion Minimum Account Length - PIC S9(3) COMP-3 
QCTMXL - Check Conversion Maximum Account Length - PIC S9(3) COMPt3 
FCTTLZ - Check Conversion Truncate Lead Zeros Indicator - PIC X(1) 
CCTPFM - Check Conversion Parsing Format - PIC 9(2) 
CCTIALC - Check Conversion Invalid Account Length Action Code - PIC X(1 ) 

Also update the views NA1VCMPR, NA2VCMPR, NA3VCMPR, and NA4VCMPR. 

SPUFI to initialize table: 

UPDATE NA001.NATBCMPR 
SET CCTIND='Y', 

QCTIAL=14, 

QCTMNL=1, 

QCTMXLL=13, 

FCTTLZ='N', 

CCTPFM=00, 

CCTILA='D' 

WHERE ACHMBRFLG = "Y" 

UPDATE NA001.NATBCMPR 
SET CCTIND='M', 
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QCTIAL=1 , 

QCTMNL=0, 

QCTMXLL=0, 

- FCTTLZ='N-, 

5 CCTPFM=00, 
CCTILA='R' 

WHERE ACHMBRFLG < 'Y' 
NATBFILS - ACF File Level 

10 

A new Check Conversion indicator in the ACF at the File ID level is required to 
indicate this customer is a Check Conversion customer. 

FCTIND -Check Conversion Indicator -X(1) 

15 

A SPUFI is used to initialize the value to "N". 

Also update view NATVFILS. 

20 NATBTFIL-ACF File Level 

A new Check Conversion indicator in the ACF at the File ID level is required to 
indicate this customer is a Check Conversion customer 

25 FCTIND - Check Conversion Indicator - X(1) . 
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A SPUFI will be used to initialize the value to "N". 

Also update view NATVTFIL. 

5 NATBCPNY - ACF Company Level 

A new Admin Returns indicator in the ACF at the Company ID level is required to 
indicate this customer is an Admin Returns customer 

10 FADMRT- Admin Returns Indicator -X(1) 

A SPUFI is used to initialize the value to "N". 

Also update view NATVCPNY. 

15 

NATBTCPN - ACF Company Level 

A new Admin Returns indicator in the ACF at the Company ID leveUs required to 
indicate this customer is an Admin Returns customer 

20 

FADMRT - Admin Returns Indicator - X(1 ) 
A SPUFI is used to initialize the value to "N". 
25 Also update view NATVTCPN. 
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Batch Programs 

New Batch Programs 

5 NAD120 - Build Check Conversion Parameter file 

This is a new program to read through the Bank File Directory (NATBCMPR) and 
build a file of the Check Conversion Parameters. The output segment is WY25 and 
it builds the plus-one generation of a new GDG 

10 PRDNA.Z1 70001 A.SCHKTPRM.R0008. 

* - ■ 

NAD300 - Check Conversion Problem Report by R/T 

This is a new program to print out a Check Conversion Problem Report by R/T. It is 
15 printed on a DAILY, WEEKLY, and MONTHLY basis called by three separate jobs. 

The returns and NOCs for ARC, POP, XCK, and RCK transactions are processed by 
this report to provide the number of returns and NOCs for each R/T. 

20 Pacbase RT1 is used to produce this report. 

NAD310 — Check Conversion Problem Report by File ID/Company ID 

This is a new program to print out a Check Conversion Problem Report by File 
25 ID/Company ID. It is printed oh a DAILY, WEEKLY, and MONTHLY basis called by 
three separate jobs. 
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The returns and NOCs for ARC, POP, XCK, and RCK transactions are processed by 
this report to provide the number of returns and NOCs for each R/T. 

5 Pacbase RT2 is used to produce this report. 

NAD31 5 - Check Conversion Detail File Builder 

This is a new program to extract the return/NOC information to build a file that can 
1 0 be sorted for the Detail Reports created by NAD320 and NAD330. 

NAD320 - Check Conversion Detail Report by R/T 

This is a new program to print out a Check Conversion Detail Report by R/T. It is 
15 printed on a DAILY basis. 

Pacbase RT3 is used to produce this report. 

NAD330 - Check Conversion Detail Report by File ID/Company ID 

20 

This is a new program to print out a Check Conversion Detail Report by File 
ID/Company ID. It is printed on a DAILY basis. 

Pacbase RT4 is used to produce this report. 

25 

NAS400 - Monthly Available Report 
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This is a new program to create the Monthly Availability Report. A new monthly 
availability report by ACH COID is created for check conversion customers. The 
fields-on the report include-processing-date 7 processing time, total itemsr total- 
dollars, RDFI, item count, and availability (0=sameday, 1=next day, 2=2 day). 

The schedule log (SCHL) is used to read the information needed for this report. 

Batch Program Changes 

CEACH01 8 - MICR Drafts 

This program is modified to include the check number on MICR DRAFTS for check 
Conversion transactions. This is for the DEBIT transactions. 

At L070864, if this is not a credit transaction and are processing a Check Conversion 
transaction (SAVESEC=ARC, RCK, XCK, or POP), move the check: number 
(MCR967) from the '6' record to 1(R1 1) to be immediately after the 7'. Ignore lead 
zeros. 

Below MCR953 there is an unlabeled CL3 statement. Put a tag "MCRSEC" on this 
line to reference the standard entry class code. 

Also add a storage field CL3 called "SAVESEC" to save the standard entry class. At 
tag ST004 after it is verified it is a '5' record, save the entry class by moving 
MCRSEC to SAVESEC. 
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It will be necessary to shift the amount to the right to allow for the, extra check 
number positions. Shift it to the right 8 positions. 

5 Also, the 15 digit TRACE for ARC, RCK, XCK, and POP transactions should use the 
1 5 digit TRACE from the '6' record, not calculated. 

NAR560 - EDIT 

10 This program is modified to check if this is a debit ARC, RCK, or POP transaction. If 
so, it preferably calls NAR562 to verify against the Check Conversion Parameters if 
the originator is set up for Check Conversion (FI00-CCTIND='Y'). 

NAR562 - MICR Split Edit 

15 

The new Check Conversion, logic preferably is only applied when the originator's 
FILE ID ACF setup has the check Conversion indicator set to "Y". 

This program is modified to look at the Check Conversion parameters in the 
20 NA4VCMPR view that is retrieved by this program. Check to see if the account 
number must be changed due to the MIN/MAX account number length parameters 
and the TRIM LEAD 0 indicator. If it must be changed, then a NOG is created. 

In 98GS, if this is a Check Conversion NOC from an original request (not a return), 
25 set AG51 -DDESC to "" rather than "WFBD". 
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Reject ARC, RCK, XCK, and POP transactions that have a check serial number with 
more than 5 digits. Need reject reason code. 

NAD-100 - Thomson File Update ■ — 

5 , 

This program is modified to set the default values for the Check Conversion 
parameters in the Bank File Directory when new bank records are inserted during 
the Thomson File Update. The insert at P92GI needs to include the new fields for 
Check Conversion parameters. 

10 

At P60BD, it adds a non-ACH bank. Set up the default check Conversion 
parameters. 

CCTIND='M',- 
15 QCTIAL=1, 

QCTMNL=0, ; 

QCTMXLL=0, 

FCTTLZ='N', 

CCTPFM=00, 
20 CCTILA='R' 

Also update the INSERT at 92GI to include the Check Conversion fields. 
NAD101 - Fed File Update 

25 
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This program is modified to set the default values for the Check Conversion 
parameters in the Bank File Directory when new bank records are inserted during 
the Fed File Update. The insert at P92GI needs to include the new fields for Check 

- Conversion parameters; — — 

5 

At P62CR, set up the default values based on FMSPL which indicates whether this is 
anACHbank. If the value of CROO-FMSPL is "Y", set up the following: 

CCTIND='Y', 
10 QCTIAL=14, 

QCTMNL=1, 

QCTMXLL=13, 

FCTTI_Z='N', 

CCTPFM=00, 
15 . CCT|LA='D' 

Otherwise, set them up to not allow check Conversion: 

FCTIND='M', 
20 QCTIAL=1, 

QCTMNL=0, 

QCTMXLL=0, 

FCTTLZ='N', 

CCTPFM=00, 
25 CCTILA='R' 
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If a R/T is being changed to non-ACH MEMBER at 58KD, set the CCTIND to 'M' to 
not allow check Conversion but to convert it to MICR. 

If-the-R/T-is-set-to-AGH MEMBER at 60APr set up-the default eheck-Conversion - 

5 parameters to allow check Conversion. 

NAG150-NOC report 

This program is modified to identify NOCS as a result of Check Conversion. A new 
10 code C99 is used when it was forced to MICR because the member bank does not 
process ACH Check Conversion transaction. 

If this NOC was a result of the Check Conversion parameters, the correct reason 
code needs to be printed on the report. 

15 

At P32BB, add the following reason codes: 

C99 - Forced to MICR because member bank does not process ACH Check 
Conversion transactions. Look for AG51 -DDESC = "WFBDM". 

20 

Also besides looking for DDESC = "NORWST", look for "WFBD" which is used for 
Check Conversion NOCs. 

Admin Returns process is to put "ADMIN" in this description field for NOCs created 
25 as a result of the Admin Returns process correcting the bank/account. 
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NAI405 - Prophet ACF/OCF Read 



This program is modified to set up a base charge for companies in which the 

FCHKTR indicator is set to -Y-at-the FILE-ID level-in NATVFILS. — 

5 

this program is modified to set up a base charge for companies in which the 
FADMRT indicator is set to "Y" at the COMPANY ID level in NATVCPNY. 

Look at FDELET indicator. 

10 

NAH720 - Monthly Return Reason Analysis Report 

This program is modified for changes to the Monthly Return Reason Analysis Report 
for the ADMIN NOCS, new C99 NOC code, and the Check Conversion Decision 
15 Rejects. 

NAC1 10 -ACF Delete 

This program is modified for the ACF Delete to add FCTIND and FADMRT to the 
20 logs. 

NAC1 20 - ACF Copy Test to Production 

This program is modified for the ACF Copy Test to Production to include FADMRT 
25 and FCTIND. 
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NAC210 - ACF Setup Report. 

This program is modified to add FADMRT and FCTIND to the ACF Setup Report. 
5 NAH400 - Returns Statistics 

This program is modified to identify DDESC='WFBD' as an ON US NOC. Where 
NORWST is being looked at in P30BJ, also look for WFBD. 

10 NAH700 - Returns Extract. 

This program is modified to also look for WFBD where it looks for NORWST. 

Batch Program Recompiles 

15 

NAC121 
NAR540 
20 NAR550 
NAR590 
NAR591 

25 

NAR592 



71 



NAR599 

. _ NAR600 ~ 

5 

Report Programs 

New Report Programs 

10 RT1 - Check Conversion Problem Report by R/T 

This Pacbase report program is used by the new program NAD300 to produce the 
. Check Conversion Problem Report by R/T. 

15 RT2 - Check Conversion Problem Report by File ID/Company ID 

This Pacbase report program is used by the new program NAD310 to produce the 
Check Conversion Problem Report by File ID/Company ID. 

20 RT3 - Check Conversion Detail Report by R/T 

This Pacbase report program is used by the new program NAD320 to produce the 
Check Conversion Problem Detail Report by R/T. 

25 RT4 - Check Conversion Detail Report by File ID/Company ID 
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This Pacbase report program is used by the new program NAD330 to produce the 
Check Conversion Problem Detail Report by File ID/Company ID. 

RHN - Monthly Return Analysis ■ "" 

5 

This program provides customers with their overall origination and return summary 
information, including return rates, redeposit rates, administrative return rates, and 
the like. 

10 Report Program Changes 

RHQ - Return Reason Analysis Summary 

This report is modified to add the number of admin returns, admin NOCs, and 
15 deposit adjustment returns. 

RHN- Return Reason Analysis Reports 

This report is for the Return Reason Analysis Report and is modified for the new 
20 lines to print. 

RC6- ACF Setup Report 

This report is modified to print the new CHECK CONVERSION and ADMIN 
25 RETURNS indicators which are now part of the ACF setup. 
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RDF - Fed File Update Report 



This report is modified to print the BEFORE/AFTER values of any Check Truncation 

-fields that change as a result of the update^ 

5 

Also display the Check Truncation data for each RT updated on this report. 
Online Programs 
10 New Online Programs 
None. 

Online Program Changes 
NAD006 

This program is modified to add new Check Conversion Database fields to the detail 
screen for the Bank Directory File. 

20 

NAC062 

This program is modified to add new Check Conversion indicator at the File ID level 
of the ACF screen NA62. This indicator should be set to "Y" or "N". 

25 
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Also, do not allow CHK TRUNC to be set to "Y" if MICR SPLIT or CU CONVERSION 
is set to "N". 



NAC063 " 

5 

This program is changed to initialize the FADMRT option for RETURNS when an 
add is being done. Add this to P29MA by setting CPNY-FADMRT to "N". 

NAC066 

10 

This program is modified to add new Admin Returns indicator at the Company ID 
level of the ACF screen NA66. This indicator should be set to "Y" or "N". 

Exemplary Report Layouts 

New Report Layouts 

The following tables show examples of new report layouts according to a preferred 
embodiment of the invention. 

20 

Table A. D300-1 Check Conversion Problem RT Report by RT 

REPORT ID: D300-1 FN 
LOCATION: 0000 
DATES: MM/DD/YY - MM/DD/YY 

25 

BANK R/T ADMIN RETURNS OTHER RETURNS 

XXXXXXXXX XXX, XXX , XXX XXX, XXX, XXX 
XXXXXXXXX XXX, XXX, XXX XXX, XXX, XXX 
30 XXXXXXXXX XXX, XXX, XXX XXX, XXX, XXX 
XXXXXXXXX XXX , XXX , XXX XXX , XXX , XXX 
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AUTOMATED CLEARING HOUSE SYS DATE: MM/DD/YY 

CHECK CONVERSION PROBLEM SYS TIME: HH : MM 

R/T REPORT . PAGE: XXXX 



PERCENT NOC 



XX % XXX, XXX, XXX 

XX% XXX, XXX, XXX 

XX% . XXX, XXX, XXX 

XX % XXX, XXX, XXX 



XXXXXXXXX XXX , XXX , XXX 
XXXXXXXXX XXX , XXX , XXX 
XXXXXXXXX XXX , XXX , XXX 



XXX, XXX, XXX 
XXX, XXX, XXX 
XXX, XXX, XXX 



XXXXXXXXX XXX , XXX , XXX XXX , XXX , XXX 
TOTAL XXX, XXX, XXX XXX, XXX, XXX 



XX % 
XX % 

xx% 

XX % 



XXX, XXX, XXX 
XXX, XXX, XXX 
XXX, XXX, XXX 
XXX, XXX, XXX 



XX % XXX, XXX, XXX 



Admin returns = R03, R04, R12, R13, R20 

Percent = Admin Returns / .{Admin Returns + Other Returns) 
TO WSF2 

ADHOC INQUIRIES FROM HISTORY SERVER 



Table B. D31 0-1 Check Conversion Problem RT Report by File Id/Company ID 

SYS DATE: MM/DD/YY 
SYS TIME: HH : MM 
PAGE : XXXX 



REPORT ID: D310-1 FN 
LOCATION: 0000 
DATES: -MM/DD/YY - MM/DD/YY 



AUTOMATED CLEARING HOUSE 
CHECK CONVERSION PROBLEM 
FILE /COMPANY ID REPORT 



FILE ID 



XXXXXXXXXX 
XXXXXXXXXX 
XXXXXXXXXX 

FILE TOTAL 

XXXXXXXXXX 
XXXXXXXXXX 



COMPANY ID ADMIN RETURNS 



OTHER RETURNS 



XXXXXXXXXX 
XXXXXXXXXX 
XXXXXXXXXX 



XXX, XXX, XXX • XXX, XXX, XXX 
XXX, XXX, XXX XXX, XXX, XXX 
XXX , XXX , XXX XXX , XXX , XXX 



XXX , XXX , XXX XXX , XXX , XXX 



XX 



XXXXXXXXXX 
XXXXXXXXXX 



XXX, XXX, XXX 
XXX, XXX, XXX 



XXX, XXX, XXX 
XXX, XXX, XXX 



FILE TOTAL XXX, XXX, XXX XXX, XXX, XXX 

TOTAL OF ALL FILES XXX, XXX, XXX XXX, XXX, XXX 

Select FILE iD' S with FCTIND » Y 



PERCENT 



NOC 



XX XXX, XXX, XXX 

-XX XXX, XXX, XXX 

XX XXX, XXX, XXX 

XXX, XXX, XXX 



XX 
XX 



XXX, XXX, XXX 
XXX, XXX, XXX 



XX XXX, XXX, XXX 

XX XXX, XXX, XXX 



Table C. D320-1 Check Conversion Detail Report 



REPORT ID: D320-1 FN 
LOCATION: * 0000 
DATE: MM/DD/YY 

BANK R/T ACCOUNT # 



AUTOMATED CLEARING HOUSE 
CHECK CONVERSION DETAIL 
R/T REPORT 



SERIAL# 



TC 



CODE TYPE 



XXXXXXXXX 


XXXXXXXXXXXXXXXXX 


xxxxxx 


XX 


R03 


ADMIN 


XXXXXXXXX 


xxxxxxxxxxxxxxxxx 


xxxxxx 


XX 


R03 


ADMIN 


XXXXXXXXX 


XXXXXXXXXXXXXXXXX 


xxxxxx 


XX 


R04 


ADMIN 


XXXXXXXXX 


XXXXXXXXXXXXXXXXX 


xxxxxx 


XX 


R12 


ADMIN 


XXXXXXXXX 


XXXXXXXXXXXXXXXXX 


xxxxxx 


XX 


R12 


ADMIN 



SYS DATE: MM/DD/YY 

SYS TIME: HH : MM 

PAGE : XXXX 

NOC INFORMATION 
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XXXXXXXXX XXXXXXXXXXXXXXXXX XXXXXX XX 
XXXXXXXXX XXXXXXXXXXXXXXXXX XXXXXX XX 



R20 ADMIN 
R20 ADMIN 



TOTAL ADMIN RETURNS 



XXX, XXX, XXX 



XXXXXXXXX 


XXXXXXXXXXXXXXXXX 


XXXXXX 


XX 


R01 


NON- 


-ADMIN 


XXXXXXXXX 


. XXXXXXXXXXXXXXXXX 


XXXXXX 


XX 






-ADMIN 


XXXXXXXXX 


XXXXXXXXXXXXXXXXX 


XXXXXX 


XX 


R08 


NON- 


-ADMIN 


XXXXXXXXX 


XXXXXXXXXXXXXXXXX 


XXXXXX 


XX 


R09 


NON- 


-admin" 


XXXXXXXXX 


XXXXXXXXXXXXXXXXX . 


XXXXXX 


XX 


RIO 


NON- ADMIN 



TOTAL NON-ADMIN RETURNS 



XXX, XXX, XXX 



XXXXXXXXX 


XXXXXXXXXXXXXXXXX 


XXXXXX 


XX 


C01 


NOC 


XXXXXXXXXXXXXXXXX 


XXXXXXXXX 


XXXXXXXXXXXXXXXXX 


XXXXXX 


XX 


C01 


NOC 


XXXXXXXXXXXXXXXXX 


XXXXXXXXX 


XXXXXXXXXXXXXXXXX 


XXXXXX 


XX 


C02 


NOC 


XXXXXXXXX 


XXXXXXXXX 


XXXXXXXXXXXXXXXXX 


XXXXXX 


XX 


C04 


NOC 


XXXXXXXXXXXXXXXXXXXXXX 


XXXXXXXXX 


XXXXXXXXXXXXXXXXX 


XXXXXX 


XX 


C04 


NOC 


xxxxxxxxxxxxxxxxxxxxxx 


XXXXXXXXX 


XXXXXXXXXXXXXXXXX 


XXXXXX . 


XX 


C05 


NOC 


XX 


XXXXXXXXX 


XXXXXXXXXXXXXXXXX 


XXXXXX 


XX 


C06 


NOC 


XXXXXXXXXXXXXXXXX XX 


XXXXXXXXX 


XXXXXXXXXXXXXXXXX 


XXXXXX 


XX . 


xC07 


NOC 


xxxxxxxxx xxxxxxxxxxxx: 


XXXXXXXXX 


XXXXXXXXXXXXXXXXX 


XXXXXX 


XX 


C09 


NOC 


"xxxxxxxxxxxxxxxxxxxxxx 



TOTAL NOC 



XXX, XXX, XXX 



BANK R/T 



ACCOUNT # 



SERIAL# 



TC 



CODE TYPE 



XXXXXXXXX XXXXXXXXXXXXXXXXX XXXXXX XX R13 ADMIN 

XXXXXXXXX ■ XXXXXXXXXXXXXXXXX XXXXXX XX Rl 3 ADMIN 



NOC INFORMATION 



TOTAL ADMIN RETURNS 



XXX, XXX, XXX 



TOTAL NON-ADMIN RETURNS XXX, XXX, XXX 



TOTAL NOC 



XXX, XXX, XXX 



Table D. D330-1 Check Conversion Detail File/Company ID Report 



REPORT ID: D330-1 
LOCATION: 0000 
DATE: MM/DD/YY 



FN 



AUTOMATED CLEARING HOUSE 
CHECK CONVERSION DETAIL 
FILE /COMPANY ID REPORT 



SYS DATE: 
SYS TIME: 
PAGE: 



MM/DD/YY 
HH : MM 
XXXX 



FILE ID 
COMPANY ID 



XXXXXXXXXX 
XXXXXXXXXX 



BANK R/T 



ACCOUNT # 



SERIAL# 



TC 



CODE TYPE 



NOC INFORMATION 



XXXXXXXXX XXXXXXXXXXXXXXXXX XXXXXX XX R03 ADMIN 
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xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


xxxxxx 


XX 


R04 


ADMIN 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


xxxxxx 


XX 


R13 


ADMIN 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


xxxxxx 


XX 


R04 


ADMIN 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


xxxxxx 


XX 


R12 


ADMIN 


xxxxxxxxx . 


xxxxxxxxxxxxxxxxx 


xxxxxx 


XX 


R20 


ADMIN 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


xxxxxx 


• XX 


R13 


ADMIN 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


xxxxxx 


XX 


_ jy jl 


A DMIN 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


xxxxxx 


XX 


R12 


ADMIN 


TOTAL ADMIN 


RETURNS . XXX 


, XXX, XXX 








xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


XXXXXX 


XX 


R01 


NON-ADMIN 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


XXXXXX 


XX 


R09 


NON-ADMIN 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


XXXXXX 


XX 


R07 


NON-ADMIN 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


XXXXXX 


XX 


R08 


NON-ADMIN 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx . 


xxxxxx ' 


XX 


RIO 


NON-ADMIN 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


xxxxxx 


XX 


R01 


NON-ADMIN 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


xxxxxx 


XX 


RIO 


NON-ADMIN 



TOTAL NON-ADMIN RETURNS 



XXX, XXX, XXX 



XXXXXXXXX 


xxxxxxxxxxxxxxxxx 


xxxxxx 


XX 


C01 


NOC 


XXXXXXXXXXXXXXXXX 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


xxxxxx 


XX 


C01 


NOC 


XXXXXXXXXXXXXXXXX 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


xxxxxx 


XX 


C02 


NOC 


xxxxxxxxx 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


xxxxxx 


XX 


. C04 


NOC 


xxxxxxxxxxxxxxxxxxxxxx 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


xxxxxx 


XX 


C04 


NOC 


xxxxxxxxxxxxxxxxxxxxxx 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx ' 


xxxxxx 


XX 


COS 


NOC 


XX 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


xxxxxx 


XX - 


C06 NOC 


XXXXXXXXXXXXXXXXX XX . 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


xxxxxx 


XX 


C07 


NOC 


XXXXXXXXX XXXXXXXXXXXXXXXXX XX 

xxxxxxxxxxxxxxxxxxxxxx 


xxxxxxxxx 


xxxxxxxxxxxxxxxxx 


xxxxxx 


XX 


C09 


NOC 



TOTAL NOC 



XXX, XXX, XXX 



Table E. S400-1 Monthly Availability Report 

-Align date/time to the right 

REPORT ID: D130-1 FN AUTOMATED CLEARING HOUSE SYS DATE: MM/DD/YY 

LOCATION: 0001 CHECK CONVERSION MONTHLY AVAILABILITY REPORT SYS TIME:. HH : MM 

COMPANY: XXXXXXXXXX * DATES: XX/XX/XX - XX/XX/XX PAGE: XXXX 



PROCESSING PROCESSING TOTAL 
DATE TIME ITEMS 



MM/DD/YY HH : MM XX XXX, XXX, XXX 



COMPANY TOTAL 



XXX, XXX, XXX 



TOTAL 
DOLLARS 



ITEM 
RDFI COUNT 



DOLLARS 



AVAILABILITY 



XXXXXXXXXX XXX, XXX, XXX X 
XXX , XXX, XXX , XXX . XX XXX , XXX , XXX , XXX . XX 

XXX, XXX, XXX 

XXX , XXX , XXX , XXX . XX XXX , XXX , XXX , XXX - XX 
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Report Layout Changes 



Tabl F. Monthly Return Analysis R port 

ORIG BANK 

091000019'" 

WELLS FARGO MINNESOTA, NAT I ON A 
6TH ST & MARQUETTE AVE 

MINNEAPOLIS MN 55479 

JANE SMITH 
ABC COMPANY 
123 A STREET 



SMALLVILLE 



CA 95123 



NATIONAL ASSOCIATION 



FILE ID: A123456789 

REPORT H12 3-N FN AUTOMATED CLEARING HOUSE 

PAGE 1 MONTHLY RETURN REASON ANALYSIS REPORT 

ACH ANALYSIS FOR 12/01 , 
ORIG BANK R/T: 456000123 
, ORIG BANK. NAME: WELLS FARGO 

COMPANY ID: A1234 5 678 
COMPANY NAME: XXXX 

FILE ID: A429483498 
FILE NAME: ABC COMPANY 

PRODUCT: OTHER CONSUMER COLL' 
FAX1:' 1-(123) 123-4567 ATTN: JANE SMITH 

FAX2: 1- (456) -321-7654 ■ ATTN: CAROL JACOB 



SYS DATE: 01/02/0 
SYS TIME : 04:56 



ACTIVITY 



ITEMS/PCNT 



ACH 



DOLLARS /PCNT 



0-5 
DAYS 



6-10 
DAYS 



>10 
DAYS 



ORIGINATED 


7,178 


100. 


0% 


XX, YYY. 


DD 


100. 


0% 








RETURNED 






















R01: 


INSUF FUND 


12 


9. 


,5% 


XXX. 


XX 


8. 


9% 


12 


0 


0 


R02: 


ACCT CLSED 


8 


6. 


,3% 


XXX. 


.XX 


6.3% 


8 


0 


0 


R03: 


NO ACCOUNT 


77 


61. 


,1% 


XXX. 


.XX 


62. 


.0% 


77 


0 


0 


R04: 


INV ACCT 


t 27 


21. 


.4% 


XXX. 


.XX 


21. 


.5% 


27 


0 


0 


R07: 


REVOKED 


1 


0, 


.7% • 


XX, 


.XX 


0 


.7% 


1 


0 


0 


R13: 


RFI INVAL 


1 


0, 


.7% 




.XX 


.0. 


. 4% 


1 


0 


0 


TOTAL 




126 


100 


.0% 


" Y, YYY 


. YY 


100 


.0% 


126 


0 


0 


REDEPOSITED 1ST REPRESENTMENT 


















R01: 


INSUF FUND 


* 9 


100 


.0% 


XXX 


.XX 


100 


.0% 









REDEPOSITED 2ND REPRESENTMENT 
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R01: 


INSUF FUND 


1 


100. 


0% 


XX. 


XX 


100. 


0% 








TOTAL 




10 


100. 


0% 


XXX. 


XX 


100. 


0% 


























===== 


======= 


======= 


RETIRED REDEPOSIT 






















R01: 


INSUF FUND 


4 


66. 


,6% 


XX. 


XX 


60. 


6% 








R02: 


ACCT CLSED 


2 


33. 


,3%_ 


_xx. 


,xx_ 


_ .3.9, 


,3% 








TOTAL 




6 


100. 


.0% 


XX. 


XX 


100. 


,0% 








NOTIFICATION OF CHANGE 






















" C01: 


ACCOUNT NO 


10 


58. 


. 8% 


XXX. 


XX 


60. 


,4% 


10 


0 


0 


C02: 


R/T NUMBER 


* 4 


23. 


.5% 


XX, 


.XX 


20. 


.6% 


3 


1 


0 


C03: 


R/T & ACCT • 


3 


17, 


.6% 


XX. 


XX 


18. 


.9% 


2 


1 


0 


C99: 


CHKT MICR 


0 


0, 


. 0% 


0. 


.00 


0. 


.0* 


0 


0 


0 


ADM: 


ADMIN NOCS 


0 


0 


.0% 


0, 


.00 


0, 


.0% 


0 


0 


0 


TOTAL 




17 


100 


.0% 


197 


.75 


100, 


.0% 


15 


2 


0 



CHECK CONVERSION XX XXX. X% 

ADMIN RETURNS 

CHECK CONVERSION DECISION REJECTS 

???.: REJECTED 4 100.0% 



XX. XX 100.09, 



TOTAL 



4 100.0% 



:x.v>: ioo.o?; 



REPORT H220-Q FN. AUTOMATED CLEARING HOUSE SYS DATE: 01/02/02 

PAGE 2 RETURN REASON ANALYSIS - SUMMARY REPORT SYS TIME: 04:56 

' ANALYSIS FOR 12/01 

ORIG BANK R/T: 123456789 
ORIG BANK NAME: WELLS FARGO/ NATIONAL ASSOCIATION 
COMPANY ID: A123456789 
• COMPANY NAME: ABC COMPANY 
FILE ID: A123456789 
FILE NAME: ABC COMPANY 

PRODUCT: OTHER CONSUMER COLL 
1ST REDEPOSIT WINDOW: 4 
2ND REDEPOSIT WINDOW: 3 
FAX1: 1-(123) 123-4567 ATTN: JANE SMITH 

FAX2: 1-(321) 321-7654 ATTN : * CAROL JACOB 

COMPANY RESULTS INDUSTRY COMPARISON 



NO. OF DOLLAR ENTRIES ORIGINATED: X/XXX 

% OF ACH ENTRIES: 100.00% 99.4% 

% OF PAC ENTRIES 0.00% 0.6% 

% OF ENTRIES RETURNED: ' X.XX% 1.8% 

NO. OF ACH DOLLAR RETURNS: XXX 

% OF RETURNS DISHONORED: 0.00% 0.3% 

NO. OF ACH PRENOTE RETURNS: 0 
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% OF PRENOTE RETURNS: 0.00% 1.7% 

NO. OF ACH RETURNS 1ST REDEPOSIT: X 

% OF ACH REDPOSITS COLLECTED: 25.00% . 52.7% 

NO. OF ACH RETURNS 2ND REDEPOSIT: 1 

% OF ACH REDPOSITS COLLECTED: 25.00% 52.7% 

NO. OF NOCS RECEIVED: 17 

% OF NOCS REFUSED: 0 . 00% Q._8%_ 

CHECK CONVERSION ADMIN RETURNS 

NO. OF CHECK TRUNC DECISION REJECTS 4 

* OF REJECTS 100.00% 



Table G. D101F - Fed File Update 



FEDERAL TAPE : XYZ . BANK DIRECTORY MONTHLY UPDATE 



ACTION : xxxxxx 

ROUTE/TRAN. : xxxxxxxxx 



RT/ FRAC. . . : 
BANK ADDR. . : 

CITY : 

. STATE : 

PHONE NBR. . : 
•THOM RETIRE: 
CHECK TRUNC : 
MTN LENGTH. : 
TRIM LEAD 0: 



xxxxxxxxxxx 



LAST CHNG. : 06/30/88 

BANK NAME. : XYZ BANK - 

ACH MEMBER: Y 

ACH MBR DT: 07/01/91 

SURV R/T. . : 

FED R/T...: 091000080 



UPDATE SRC: 
MIDDLE TOWN 



xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 



XX 

(xxx) xxx-xxxx 

XX / XX / XX 



ZIP CODE. 



xxxxx xxxx 



FED RETR.-.: xx/xx/xx 
INV LENGTH: XX 
•MAX LENGTH: XX 



BANK STAT . : 
STAT DATE. : 
INST TYPE. : 



A 

07/01/91 
01 



INV LENGTH ACTION: 
PARSE FORMAT : 



Exemplary Online Screens 

The following tables show sample online screens according to one embodiment of 
the invention. 



Table H. NA06 - Bank Directory Detail 



NA06 


WELLS FARGO BANK DIRECTORY DETAIL 


02/21/02 11:06 






LAST CHNG. : 02/16/99 


ACTION : 


(A-ADD, C-CHANGE) • 


CHANGED BY: MAINELSO 1 






UPDATE SRC: 


ROUTE/TRAN: 


091000XXX SURVIVE RT : 0 


BANK STAT . : A 


RTE SYMBOL: 


0XX ACH MEMBER: Y 


STAT DATE.: 04/18/92 


R/T FRAC . . : 


01XXXXXXXXX ACH MBR DT : 05/12/89 


ASSOC NAME: 


BANK ABA. . : 


XXXXXX ACH CONTCT: 
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CU ID POS. : 


CU ID : CU PROCESR: 000000000 




CU R/T FLG: 


CU ACT FLG: CU PROCESS: 




CHK TRUNC : 


X LEGNTH INV: XX ACT: X MTN : XX MAX: XX FORMAT: XX TRIM LEAD 0: X 




BANK NAME. : 


XYZ BANK MINNESOTA, NATIONAL ASSOCIATION 




STREET ADR: 


zzzzzzzzzzzzzzzzzz 




CITY : 


XXXXXXX _ 






XX ZIP CODE..: 12345 PHONE NBR. : (321) 123-4567 




MBR OVRD. . : 


OVRD DATE.: THOMP RETR: / 0/ FED RETIRE: / 0/ 




REASON : 






INDMNTY RQ: 


PRENOTE RQ: 




SPEC INSTR: 

i 






NEXT TRAN: 


INPUT: r 5003 PF: 





Table I. NA62 - ACF File ID Level 



NA62 


ACF FILE SETUP 




02/20/02 10:23 






LAST CHNG. : 01/24/02 


ACTION. . . . : 


(A=ADD, C=CHG, D=DEL) DELETE FLG' 


CHANGED BY: 


REGION CDE: 


OX MULT CPNY. : 


MULT BTCH . : 


LOCATION. . : 


0000 CUST SPPRT: 0000 


SHORT NAME : 


FILE ID. . . : 


FILE OWNER: 






ADDR 1ST. . : 




CIS UPDATE: 


N CI SABA: 


ADDR 2ND. ..: 




CIS DDA. . . : 




CITY : 




STATE: 


ZIP:. 


DELIV METH: 




MVS APPLID: 




ORIG TYPE . : 


TXMT TYPE . : - MOD OVERLY : 


USER ID. . . : 


XXXXXXXX 


MICR SPLIT: 


CU CNVRSN. : R/T ACCT. . : ■ 


R/T ACCT #: 


0 


MICR SPPRT: 


'MICR SETL.: FILE SETL.: 


BATCH REPT: 


N CHK TRUNC: X 


CPNY REP. . : 


WORK: { ) 


HOME: 


(999) 999-9999 


RISK REP. . : 


WORK: ( ) 


HOME: 


(999) 999-9999 


AFTER HRS1: 


UNKNOWN WORK: (999) 999 


-9999 HOME: 




AFTER HRS2: 


WORK: 


HOME : 




CSMGT REP. : 


WORK : 


HOME: 




ACCT OFFCR 


WORK: ( ) 


RISK: 


SCHD: 


PF5 CPNY\BATCH, PF7 PREV FILE, PF8 NEXT FILE, PFll RISK\COMM, PF12 SCHEDULE 


NEXT SCREEN 






4723 PF: 



Table J. NA66 - ACF C mpany ID L vel 
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NA66 


ACF RECEIVED RETURNS 03/07/02 16:45 










LAST CHNG. : 






ACTION : 


(C=CHG) DELETE FLG: 


CHANGED BY: 






REGION CDE: 


LOCATION. . : RPTG ABA. . : 


SHORT NAME: 




5 


FILE ID. . . : 


FILE OWNER: 








COMPANY ID: 


COMPANY . . . : 












• — -— — ■- 


- - 




RTN ATTN . . : 


, RTN CO: 








RTN ADD1 . . : 
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RTN ADD2 . . : 










RTN CITY. . : 


RTN STATE. : 


ZIP CODE. . : 






FLOAT BYP . : 


ADM RETURN: X 








BYPASS R/T: 


BYPASS ACT. : 


ACCT TYPE. : 






RTN R\T. . . : 


RTN ACCT . . : 


ACCT TYPE. : 




15 












RDPST CDE. : 


RDPST LOW. : 


RDPST HIGH: 






RDPST NBR. : 


RDPST HIST: 


RDPST WIND: 






DISH -CODE. : 


DISH LOW. . : 


DISH HIGH. : 






. UNTIMELY. . : 


REPAIR FLG: 


TAPE RET. . : 


• 


20 


RTN MEDIA. : 


RTN ANALY.: RTN SRT OPT.: 


COMP EXIT. : 






GEN INSTR. : 










INVALID VALUE FOR THE FIELD LAST 


CHANGE DATE 






NEXT SCREEN: 




PF: 





25 

Accordingly, although the invention has been described in detail with reference to 
particular preferred embodiments, persons possessing ordinary skill in the art to 
which this invention pertains will appreciate that various modifications and 
30 enhancements may be made without departing from the spirit and scope of the 
claims that follow. 
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